home *** CD-ROM | disk | FTP | other *** search
/ Skunkware 5 / Skunkware 5.iso / src / X11 / xconq / Doc / xconq.ms < prev    next >
Text File  |  1995-05-09  |  29KB  |  609 lines

  1. ./" SCO SCCS ID: @(#) xconq.ms 12.1 95/05/09 
  2. .TL
  3. LIBERATING THE WORLD (Made Simple)
  4. .AU
  5. Stan Shebs
  6. .AI
  7. Department of Computer Science
  8. University of Utah
  9. .AB
  10. This is an in-depth document on version 5 of the \fIxconq\fP
  11. family of programs.
  12. Version 5 is quite different from earlier versions;
  13. players familiar with those should read everything in here,
  14. especially the section on important changes.
  15. All aspects of play are covered.
  16. Details on customization may be found in a companion document.
  17. .AE
  18. .SH INTRODUCTION
  19. .PP
  20. .I
  21. War is a matter of vital importance to the State; the province of life
  22. or death; the road to survival or ruin.  It is mandatory that it be
  23. thoroughly studied.  -- SUN TZU (ca 400 BC)
  24. .R
  25. .LP
  26. Welcome to \fIxconq\fP,
  27. a chance for you to free the world from domination by evil empires.
  28. It is similar to previously distributed empire-building games,
  29. but with many more features.
  30. The same basic game is available with several different interfaces.
  31. \fIXconq\fP
  32. is a fully X-based multi-player game, allowing almost any combination
  33. of human and machine players, and opening up remote X windows as necessary.
  34. There is also a restricted variant \fIcconq\fP
  35. that needs the curses terminal package only, but allows only one human
  36. player.
  37. .LP
  38. In the standard game,
  39. you start with one city and no knowledge of the world beyond your
  40. immediate vicinity.  You must then explore, contact, and win wars against
  41. all the other players, who are trying to do exactly the same things to you!
  42. This is made harder by the limited information that the game supplies;
  43. except for the vicinity of your own possessions (and for certain type of
  44. units), the entire view
  45. is out-of-date, and you won't see enemies until they're close by.
  46. .LP
  47. The "standard game" is played on a small (usually 60x30 hexes) randomly
  48. generated map, against one machine player.  Your first
  49. city will automatically start building your first military unit (usually
  50. infantry).
  51. When it is ready, the starting city will be overwritten by a picture of
  52. the unit, which is itself surrounded by a box-shaped
  53. cursor (the "unit cursor").
  54. The mouse (or standard Unix direction keys) may then be used to designate
  55. any location for that unit to move to.  This movement may take several
  56. turns, or the unit may stop before it gets there, usually because it is
  57. adjacent to something unfriendly.  To attack, just direct the unit to
  58. move into a hex that shows another unit, and see what
  59. happens (flashes, and maybe a notice at the top of the screen).
  60. When you capture some kinds of units (usually cities),
  61. \fIxconq\fP will ask you what sort of units
  62. you want that unit to produce; '?' will display the possibilities.
  63. .LP
  64. In general, '?' will always work.  When typed during normal movement,
  65. you will get a series of help screens, including commands, news, and
  66. unit characteristics. (This info may be written into printable files if the
  67. interface doesn't have the screen space necessary.)
  68. '/' will tell you what you are looking at on the screen.
  69. .LP
  70. The foregoing is sufficient to play - just jump in and go!
  71. After a few games, it should be clear what your units can and cannot do.
  72. The game will end automatically when your opponents are no longer capable
  73. of winning (either they have nothing left or they have given up).
  74. The following sections contain many boring details, and should be referred to
  75. for answers to questions.
  76. .SH
  77. DEFINITIONS OF TERMS
  78. .LP
  79. An xconq game involves several \fIsides\fP,
  80. each of which has a human or machine player associated with it.
  81. Sides may be enemies, allies, or neutral with respect to each other,
  82. often start out in a hexagonal \fIcountry\fP.
  83. A side owns a number of \fIunits\fP,
  84. which includes the cities and the armed forces of that side.
  85. Units may also be \fIneutral\fP, and belong to no side
  86. (this is different from being on a neutral side).
  87. Units may be inside other units, in which case the one inside is in
  88. \fIoccupant\fP, and the other is a \fItransport\fP (even if it can't move).
  89. Units always have \fIorders\fP that they follow, even when they appear
  90. to be under manual control.  There are also \fIstanding orders\fP that
  91. get passed to occupants automatically.
  92. The game is divided into a number of \fIturns\fP,
  93. during which each side gets to move some or all of its units.
  94. All the action happens over a \fImap\fP of a real or imaginary world that is
  95. divided into hexagonal shapes usually called \fIhexes\fP.
  96. Each hex has a \fIterrain\fP assumed to cover the entire hex.
  97. In some games, hexes also have a \fIpopulace\fP belonging to some side.
  98. Terrain on the map can produce \fIresources\fP,
  99. which are natural items ranging from water and food to gold and weapons;
  100. resources being carried by a unit are also called \fIsupplies\fP.
  101. \fIScenarios\fP are predefined games that set up maps, sides, units, and
  102. \fIwin/lose conditions\fP, which define the circumstances under which
  103. one or more sides win or lose in the scenario.
  104. .LP
  105. The numbers and kinds of units, resources, and terrain are not built in;
  106. they are defined by a historical (or ahistorical!) \fIperiod\fP.
  107. This means that the following sections will be somewhat vague on specific
  108. units and behaviors, since
  109. the information applies to times ranging from Ancient Greece to Star Wars.
  110. Later sections will describe some of 
  111. the periods that have been developed so far;
  112. in addition, complete online help is available on the period in effect.
  113. .SH
  114. THE WORLD
  115. .PP
  116. .I
  117. Geography defines the background to conflict.  Gold mines are usually in the
  118. mountains, far from the sea.  Islands tend to be left alone, unless they
  119. are on a direct path somewhere else.  A seacoast town can be strategically
  120. useless if its approach is through shallow water.  Attention to terrain
  121. and its effect on one's units can make the difference between
  122. winning and losing.
  123. .P
  124. .LP
  125. The world map on which you play is a cylinder of variable height and diameter.
  126. Although it is always displayed as a rectangle, you can actually
  127. circumnavigate the world.  The most northerly and southerly
  128. rows of hexes are out of bounds.
  129. Sizes can range from 20x20 "quicky" maps to the 
  130. Earth at 1 degree resolution between
  131. 60 north and 60 south - no less than 360 by 120 hexes! 
  132. When starting up, you have the
  133. choice of several maps of real areas, depending on the period, or by
  134. default you get a randomly-generated 60x30 map. You can get other sizes
  135. from about 10x10 up to whatever your machine's memory can hold,
  136. by using the \fB-M\fP option on the command line.
  137. The \fB-m\fP command line option loads a named map,
  138. and the \fB-x\fP option may also offer a menus of maps to use.
  139. Predefined maps usually have their own documentation, which is displayed
  140. on one of the help screens.
  141. .LP
  142. Each individual hex of the world contains one kind of terrain,
  143. which is assumed to more-or-less cover the entire hex.
  144. The exact set of terrains depends on the historical period; the set
  145. below is from the standard period, and is actually shared by many
  146. periods.
  147. Monochrome \fIxconq\fP uses icons for each type of terrain, which cannot
  148. possibly be described verbally, so use the help commands to decipher them.
  149. .IP
  150. Sea (dark blue) is assumed to be deep enough for any ship.  Armies can't
  151. walk on water.
  152. .IP
  153. Shallows (light blue or cyan) include shoals, reefs, rivers, and any
  154. other sort of shallow water.  They restrict movement of ships and
  155. may entirely prevent passage of the largest ships.
  156. .IP
  157. Plains (light green) are generally flat and hospitable areas.
  158. They usually offer no impediments to movement.
  159. .IP
  160. Forest (dark green) is dense forest or jungle, and may hinder movement for
  161. some kinds of units.
  162. .IP
  163. Swamps (gray) are half water and half land, and impassable to almost
  164. everybody.
  165. .IP
  166. Desert (yellow) ranges from Saharan sands to Sonoran cacti.  It is always
  167. inhospitable but fast to move through - think of armor in North Africa.
  168. .IP
  169. Mountains (brown) are relatively barren and at higher elevation, thus are
  170. also inhospitable to troops.
  171. .IP
  172. Ice (white) is deep snow, ice, and glaciers.  Only specially equipped
  173. ground units can pass over it, although most aircraft can fly over.
  174. .IP
  175. Vacuum (black) is outer space, included for the purpose of doing futuristic
  176. periods.
  177. .LP
  178. Each hex is adjacent to six others, and there is no special border to cross.
  179. By default, hexes represent areas about 100 km on a side, although many
  180. maps have larger or smaller scales.
  181. .LP
  182. Randomly generated maps vary in their "roughness", and in the percentages
  183. of each kind of terrain.  These properties also depend on the period, and
  184. it is worthwhile to have a general idea of the values.  Percentage coverage
  185. is simple (for instance, the earth is 70% covered by water), but roughness
  186. is more subtle; essentially the "jagginess" of the terrain.  Very rough
  187. terrain has lots of sharp peaks and small islands, while smooth terrain
  188. has large flat continents.
  189. .LP
  190. SIDES
  191. .PP
  192. .I
  193. Politics provides the context for war; the war being a result of failed
  194. policy.  The leader of a country is faced with the problem of achieving
  195. certain goals, either externally- or self-imposed.  Diplomacy can sometimes
  196. accomplish the desired outcome, and is much cheaper to boot.  When it fails,
  197. one country or another declares war, and any alliances immediately broaden
  198. its scope.  Declaring peace again is much more difficult...
  199. .R
  200. .LP
  201. Sides in the game can be allies or enemies in various combinations.
  202. Any two sides can form a formal alliance; human players do it by sending
  203. the message "alliance" to each other using the message command (see below).
  204. Machine players
  205. are "aware" of their relative incompetence, and will usually ally with each
  206. other (except in the case of a machine player attached to a display, so as
  207. to facilitate debugging).
  208. Players may become neutral or declare war by sending the messages "neutral"
  209. and "war" to another side.
  210. Scenarios may sometimes set up particular patterns of alliances, although
  211. there is nothing to prevent the players from changing them around during
  212. the game.
  213. If all the sides left in a game are allied, then it automatically ends.
  214. .LP
  215. Some displays distinguish alignments by using the same colors for
  216. allies as for yourself, while painting neutrals and enemies in distinctive
  217. colors.  For others, you just have to remember who is on whose side.
  218. .LP
  219. Names of sides come from a scenario or are randomly generated from a list
  220. of names, depending on period.  If the period doesn't define any names for
  221. sides, then the list will be 100+ contemporary names (including Botswanans
  222. and Peruvians).
  223. Players may also rename themselves, using a command (see below).
  224. Since it is usually hard
  225. to remember which player has which name, many mentions of sides include
  226. the display that the side is using (or nothing if a machine player), or
  227. sometimes the number of the side (especially for input).
  228. .LP
  229. When a side loses, for whatever reason, units are either destroyed or made
  230. neutral (depending on unit and period).  In the standard period, infantry
  231. is destroyed, while cities become neutral (thus easy pickings for the
  232. remaining players who get to them the quickest).
  233. .LP
  234. Informal
  235. alliances frequently happen in games involving more than two people, so
  236. I have a few words of advice.  First, an alliance between two of the
  237. players is almost certain in a three-person game, and inevitably
  238. results in the "odd man out" being quickly defeated.  In four-person
  239. games, the alliances should be decided after looking at the map via "-v",
  240. so that one pair is not hopelessly separated.  Five or more players is
  241. going to be a free-for-all of formal and informal alliances.
  242. Some scenarios are designed with a particular number of players in mind;
  243. hopefully they will also have some natural balance.
  244. .SH
  245. UNITS
  246. .PP
  247. .I
  248. War is based on the application of force to the other side, using
  249. whatever is available; from spears and arrows to the high-tech equipment
  250. available as a significant fraction of a nation's GNP.
  251. .P
  252. .LP
  253. Units can be almost anything: armies, balloons, triremes, cavalry,
  254. battleships, bridges, headquarters, cities.
  255. Units move around, attack other units, produce resources, 
  256. and build more units, among
  257. other things.  Individual units occupy entire hexes, and no other unit
  258. can enter that hex unless it can occupy or be occupied by the unit already
  259. there.
  260. .LP
  261. Only some kinds of units can build other units,
  262. at a rate depending on the period, the
  263. unit being built, and the unit doing the building.
  264. The first unit that is produced takes
  265. somewhat longer, and the very first unit built by a side can take even
  266. longer (research and development time),
  267. but then succeeding units come out at a constant rate.
  268. There is no memory about production, so switching to a different type then
  269. switching back still incurs the extra startup time.
  270. Most units that do building will do it all the time, and only stop when
  271. explicitly directed to (such as cities), while others need to be directed
  272. to build, and cannot move while doing so (such as engineers building a base).
  273. .LP
  274. Once created, a unit moves according to its orders, and subject to various
  275. constraints - armies can't swim, ships can't walk, etc.
  276. Units can sometimes be disbanded with a command (depending on the period),
  277. by losing them
  278. in battle, by running out of supplies, by being taken prisoner when a unit
  279. is captured, or by garrisoning a captured unit.
  280. .LP
  281. Every unit starts out with a
  282. number of \fIhit points\fP representing its strength,
  283. and possibly supplies of
  284. food, fuel etc that it carries around.
  285. Supplies are used up by movement, combat, and by just existing, and are
  286. created by production on certain terrain types, or by transference from
  287. some other unit.
  288. .LP
  289. There is only one situation under which several units
  290. can be in the same hex at once;
  291. if one is a transport of some sort and the others are its passengers
  292. or occupants.
  293. The notion of "transport" and "occupant" is general, and covers
  294. fighters on carriers, ships in port, bombs in bombers, and troops being
  295. led by a general.
  296. Occupants board by moving
  297. into the hex occupied by the transport, but will refuse to go if the
  298. transport is full or can't carry that type of unit.  Getting on board
  299. takes a number of moves of that unit; if there are any left, it may move
  300. off or take some other action.
  301. Transports can also move over a occupant to take it on, but only if the
  302. transport can move on the terrain that the occupant is on.
  303. Occupants always move with the
  304. transport (that's what transporting is all about!),
  305. but may leave at any time if possible, either onto a valid terrain
  306. or onto another transport.
  307. To debark, just
  308. move the unit off (the cursor indicates that the occupant
  309. and not the transport is to be moved).  Usually, you will want to put the
  310. occupant on sentry duty while moving the transport, and so must wake the
  311. occupants up before they can be moved again.
  312. .SH
  313. THE GAME
  314. .LP
  315. Games may be predefined scenarios, which define the map, sides, and units,
  316. or they may be randomly generated.  If randomly generated,
  317. depending on the period, you start with either a country-full of units
  318. or just one, which may or may not have its production defined already.
  319. If you start with one, the period may also define some neutral units
  320. in your country, which should be captured as quickly as possible.
  321. .LP
  322. Sometimes the map will be too small or have the wrong terrain, and then
  323. \fIxconq\fP will fail at placement and exit instantly.  There is not much
  324. you can do at that point except to try again or relax the constraints,
  325. perhaps by reducing the number of sides or increasing the map size.
  326. (This can also be fixed by altering the period - see the customization
  327. document for details.)  Since there is a lot of randomness in placement,
  328. second tries are frequently successful, although tenth tries usually indicate
  329. a real problem.
  330. .LP
  331. A turn consists of several phases, although only one actually involves
  332. player interaction:
  333. .IP Spy\ Phase 5
  334. Leakage of information from one side to another.
  335. .IP Disaster\ Phase 5
  336. Revolts, surrenders, attrition, and accidents.
  337. .IP Build\ Phase 5
  338. Construction of new units and repair of damaged ones.
  339. .IP Supply\ Phase 5
  340. Production and distribution of resources.
  341. .IP Movement\ Phase 5
  342. Automatic and manual movement of all units.
  343. .IP Consumption\ Phase 5
  344. Details relating to supply usage during movement.
  345. .LP
  346. During the movement phase,
  347. the program iterates through all units, prompting each side to give
  348. orders to any unit that is awake or becomes awake during the course of
  349. its move.  One consequence is that you will not have a chance to change
  350. orders, look around, or do anything else 
  351. if no unit produces a unit and no units
  352. wake up.  This speeds playing but can be annoying if you get overrun and
  353. lose without ever getting a chance to respond (but do you deserve anything
  354. else for pursuing a "hands-off" management strategy?).  Sides that
  355. lose are automatically cut out of the game.  Since one additional iteration
  356. is needed to verify that somebody lost, the final winner will have to go
  357. through an entire turn before the game will exit (doing the sentry command
  358. on everything is easy and quick).
  359. .LP
  360. The game ends when the win/lose conditions have been met; these vary
  361. from scenario to scenario.
  362. For a randomly-generated game, the end comes when no mutual enemies are left,
  363. whether by elimination or by peace.
  364. Usually this means
  365. that only one side is left alive, but multiple machine players (not
  366. associated with displays - the usual case) are always allied, and thus
  367. may win as a group.  This also means that a single member of the alliance
  368. will not resign until the position of the whole alliance is hopeless;
  369. after all, the WWII Allies included several brigades of Polish troops
  370. after Poland was overrun.
  371. .LP
  372. The last player must type a key to close down the
  373. windows (this is so that they will stay up for everybody to look at).
  374. When the game closes down, the winners (if any) will be listed.
  375. If the STATISTICS option has been set by the installer, \fIxconq\fP
  376. will write a file "stats.xconq" into the current directory.  This file
  377. summarizes some crucial statistics concerning combat performance, losses,
  378. and other miscellany.  It is quite useful for rationalizing your
  379. humiliating defeat!
  380. .SH
  381. DISASTER PHASE
  382. .PP
  383. .I
  384. War is inherently random.  Both military and civilian units desert,
  385. get diseases, have accidents, defect, and surrender without a struggle.
  386. These effects cannot be eliminated completely,
  387. but can be reduced by keeping one's forces out of hazardous situations
  388. and by keeping morale up.
  389. .P
  390. .LP
  391. Three types of disasters can befall a unit during the disaster phase:
  392. revolt/surrender, attrition, and accidents.
  393. .LP
  394. Revolts and surrenders are really the same sorts of occurrence; a unit
  395. changes sides spontaneously, perhaps to neutrality, perhaps to the side
  396. of a nearby enemy unit.  During every disaster phase, each unit makes
  397. a revolt check.  The revolt chance is a hundredth percentage.
  398. When a unit revolts, it changes to its original side (whatever the
  399. unit started out as - i.e. your initial units will never revolt).
  400. Occupants will either change over or be killed.
  401. Any construction will be cancelled, unless the scenario is one in which
  402. construction changes are not allowed.
  403. .LP
  404. Surrender only occurs if a unit is
  405. capable of capture is present.  The capturing unit does not move.
  406. Occupants of the surrendering unit also change over or die.
  407. Chance of surrender is increased by low unit morale.
  408. .LP
  409. The chance of surrender can be greatly increased (depending on period)
  410. by surrounding the unit completely.
  411. This includes naval units
  412. for any sea hexes.  One of the surrounding units must be capable (even
  413. if only a small chance) of capturing the unit by direct attack.
  414. The siege is only in effect
  415. in those turns where the unit is completely surrounded.
  416. When the unit surrenders, one of the "capture-capable" units will be randomly
  417. picked to accept the surrender, and things happen as for a direct assault
  418. (described below).  Note that if several sides are surrounding the same
  419. unit, the selection is still random from among those sides, as long as the
  420. side is an enemy.
  421. .LP
  422. Attrition is a "slow death" process applicable primarily to multi-hp
  423. units.  It takes away some number of hit points
  424. each time it occurs, and kills units only if they have no points left.
  425. Attrition is also specified in hundredths of a percent,
  426. and depends on unit type and terrain type.
  427. Morale drops by 1 when attrition occurs.  A message will be displayed as well.
  428. .LP
  429. Finally, there is a chance for an accident to destroy a unit instantly and
  430. totally.  Like attrition, this depends on both unit and terrain type, and
  431. is measured in hundredths of a percent.  If the accident occurs, the unit
  432. is killed along with all occupants.  A message will be displayed.
  433. .SH
  434. BUILD PHASE
  435. .PP
  436. .I
  437. Sustained efforts in a war depend vitally on the replacement and
  438. repair of forces destroyed or damaged in combat.  In total war,
  439. the production base constitutes a chief strategic target, to be
  440. isolated or destroyed if possible.  Repair of units is also significant
  441. since a battle may result only in damage, but be successful nevertheless
  442. if units must retire (as a cheaper alternative to new production).
  443. Historically, battle damage has resulted in the termination of an
  444. entire campaign.
  445. .P
  446. .LP
  447. During the build phase, units construct new units and repair damaged
  448. occupants (or themselves).
  449. .LP
  450. Construction is straightforward; the schedule is decremented once/turn.
  451. When it has counted down to zero, the unit is created, and placed either
  452. as an occupant of the builder, or the builder is made to occupy the new
  453. unit.  If neither alternative works (perhaps because the builder is full
  454. already), then completion is postponed, and attempted on the next turn.
  455. This will be repeated indefinitely.  If the new unit cannot be placed at
  456. all, it is thrown away.  If the period specifies that the builder is to
  457. guard the new unit, then the builder will be assigned to garrison the new
  458. unit, and is destroyed.
  459. .LP
  460. Repair happens automatically if the damaged unit contains or is contained by
  461. another unit
  462. capable of repairing, or if the unit can repair itself.
  463. The repair rate is depends on both the repairer and repairee,
  464. and can happen no faster than one hp/turn.
  465. .SH
  466. SUPPLY PHASE
  467. .PP
  468. .I
  469. The Allies floated to victory on a sea of oil.  -- LORD CURZON.
  470. .P
  471. .LP
  472. Resources themselves are basically inanimate material that come in varying
  473. amounts and are governed by conservation laws.  They can be produced,
  474. moved around, and consumed during various activities.
  475. Resources originate either as supplies carried by units at the outset,
  476. or more typically, through production by units.  Production rate
  477. depends on unit, resource, and terrain types, and is unaffected by
  478. side changes, combat, or anything else.  Produced resources go into
  479. the producing unit's storage.
  480. .LP
  481. Excess production is discarded, unless it can be unloaded into the
  482. producer's occupying units, or distributed to nearby units via
  483. \fIsupply lines\fP.  Supply lines automatically exist between units
  484. that are close enough (as decreed by the period), and there is no
  485. need for explicit manipulation.
  486. .LP
  487. Units consume their supplies, both in the course of existence,
  488. and by motion/combat.
  489. The rate depends on period and unit type; it consists of an overhead
  490. consumed each turn without fail, and consumption for each hex of movement.
  491. The total is a max, not a sum, since units with a constant consumption
  492. rate are not likely to need additional supplies to move (consider foot
  493. soldiers who eat as much sitting around as they do walking).
  494. Supplies may also be consumed for production and repair, again depending
  495. on period and unit types, but this consumption happens during the build phase.
  496. Consumption is not affected by the situation of the consuming unit;
  497. armies in troop transports eat just as much as when in the field.
  498. .LP
  499. Supply line length depends on the period and the units on both ends,
  500. but is not affected by the intervening terrain.
  501. Supply redistribution is managed by logistics experts, who are ignorant
  502. of the war effort and seek only to even everything out.
  503. The redistribution method is rather adhoc; units try to get rid of all
  504. their excess supply, and try to take up supply from other units within
  505. supply range.  Each direction is controlled independently, so for instance
  506. airplanes can get automatically refueled from a nearby city, but not from
  507. each other.  No unit will transfer all of its supply via supply lines.
  508. Normally units in the same hex can exchange supplies, but some periods
  509. can disable this behavior, so that explicit transfer using the give and
  510. take commands is always necessary.
  511. .SH
  512. MOVEMENT AND COMBAT
  513. .LP
  514. The movement phase is the one in which all the action happens.
  515. At its outset, the phase computes the number of moves available to
  516. each unit.  This value is essentially the maximum of the unit's moves
  517. on each type of terrain.  The movement phase continues until all these
  518. moves have been expended in some way or another.
  519. .LP
  520. Some periods may define a small chance of random movement, in which the
  521. unit moving actually goes in some other direction than that intended.
  522. This is a potentially dangerous occurrence, since the unit will be
  523. destroyed if the hex is impassable or contains another unit (whether
  524. or not the other unit can take the moving one as an occupant).
  525. .LP
  526. All combat occurs during the movement phase.
  527. Battles happen when one unit attempts to move onto a hex occupied by
  528. an unfriendly unit.
  529. In most periods, each unit attacks the other equally well, but if
  530. "counterattack" is not enabled, then the defender just has to sit and
  531. take the punishment.
  532. The outcome
  533. is determined independently for each unit, based on a probability table;
  534. this means that both draws and mutual damage/destruction are possible.
  535. The odds are the same whether a unit is attacking or being attacked.
  536. Ammunition may be expended by each unit in each combat - if the ammo is
  537. gone, then the attacker will not attack and the defender cannot defend itself.
  538. The results are announced both by a message and by some flashes on the
  539. screen (the size of the flash corresponds to damage seriousness).
  540. Damage is assessed using hit points, and if the hit points are zero, the
  541. unit is destroyed, along with any occupants.  Typically armies have only
  542. one hit point each, so they are destroyed if hit.
  543. Units with multiple hit points may be \fIcrippled\fP if their hit points
  544. drop below a period-specified level.  Crippled units move more slowly
  545. (in proportion to their damage), have reduced transport volume, cannot
  546. repair anything, and do not make progress on any construction.
  547. The final outcome of combat
  548. depends on whether the defender was destroyed.  If so, the attacker will
  549. move into the defender's position (if possible), otherwise no movement
  550. will happen.
  551. .LP
  552. If a unit
  553. is hit sufficiently hard, that is
  554. considered a "nuke" and you get more spectacular visual effects, plus
  555. the hex is converted into desert or something else desolate.
  556. .LP
  557. Some units are capable of capturing other units, with a probability depending
  558. on the types of both units involved.  If the capture attempt is successful,
  559. the capturer will move into the hex if possible, either as occupant or
  560. transport.  In some periods, the capturer may be all or partially disbanded,
  561. to serve as guards.
  562. The regular attack as described above always happens first.
  563. .SH
  564. ORDERS
  565. .PP
  566. .I
  567. A perennial feature of the highest level of command is its inherent
  568. complexity.  Although the use of subordinates reduces the bewiderment
  569. somewhat, the commander-in-chief must still keep in mind hundreds of
  570. apparently unrelated facts; the state of the weather, the past performance
  571. of units, the current goals of the war, and many other things.
  572. It is very important that lower-level units be able to operate on their
  573. own as much as possible.
  574. .R
  575. .LP
  576. Although units have been said to "move", in actuality they follow orders,
  577. some kinds of which specify movement.  When you are moving a unit
  578. hex-by-hex, it is following the order "Awake",
  579. which just means that every turn it asks what to do next.
  580. There are many kinds of orders.  Some, such as movement in a given direction,
  581. or to a given place, take parameters, but all take a repetition, which
  582. tells for how many turns the unit will carry out the order.
  583. (For some orders, the repetition is not particularly meaningful,
  584. and is ignored.)
  585. Repetition is always specified as a prefix numeric argument to commands.
  586. .LP
  587. Orders that a unit can do include:
  588. .IP Awake 10
  589. ask for a movement or other command.
  590. .IP Sentry 10
  591. sit at the present location as long as the repetition says.
  592. .IP MoveDir 10
  593. move in the given direction.
  594. .IP MoveTo 10
  595. try to move to the given location.
  596. .IP FollowCoast 10
  597. attempt to follow a coastline.
  598. .IP FollowLeader 10
  599. move towards another given unit (which must be one of your own).
  600. .IP Patrol 10
  601. go back and forth between two points.
  602. .LP
  603. Most movement commands just give these orders to the unit currently being
  604. prompted about.  In addition, a unit may be given "standing orders", which
  605. will be passed to any unit of a particular type entering or produced in that
  606. unit.  This is useful for a variety of purposes, such as staging fighter
  607. planes up to the front lines or sending ships out on standard patrols.
  608. .so xconq2.ms
  609.